本文作者：kayeelao，腾讯TEG产品策划
一、导语
作为一个产品经理，我们最离不开的一个词，就是“需求”。能传达我们对需求的理解与定义的工具就是产品需求文档。而产品需求文档也是贯穿于整个产品设计研发过程中的一个关键指导纲领。
在工作期间，我撰写了不少需求文档，同时在理解需求、表述需求、实现需求的过程中不断磨练自己的产品思维。因而撰写此篇文章，尝试通过具体经验反思总结，形成系统化、可实践复用的关于产品需求文档撰写的方法论。希望这篇文章能帮助同样是产品新人的同学们学会用产品思维撰写需求文档，并运用到其他的策划工作中。
本文将围绕是什么、为什么、怎么写产品需求文档以及用产品思维讲述如何写好需求文档，让需求文档助力产品落地上线。
二、 什么是产品需求文档？
产品需求文档（简称PRD）是产品项目由“概念化”阶段进入到“图纸化”阶段的一个最主要的文档，是对需求进行规划、定义、描述和展示的工具。
通俗点来说，产品需求文档就是产品经理在获得一个产品需求（用户的需求、竞品分析、运营团队、战略目标等）后，对需求进行理解、梳理和定义描述后的产物。它传达了产品经理对这个功能需求的构想与预期，是产品研发工作流程中至关重要的依据。
三、 为什么要写产品需求文档？
1. 产品需求文档是产品设计研发过程中的指导纲领。
为了直观地阐述PRD在产品设计研发过程中起到的作用，绘制了一个表格描述各工作环节中，各成员是如何利用PRD进行工作的。
由上表可见，每一个环节都需要以产品需求文档为依归。
2. 产品需求文档是产品工作流程中各个环节对需求描述和传达最快速的工具，减少沟通成本。从上述的产品流程中可见，每一个环节和项目干系人都需要理解需求的定义和描述，通过文档对需求的传达，能减少产品经理在各环节与各方的沟通交流。3. 产品需求文档保证各部门沟通有理有据，还可以为产品质量控制做好保障。当产品设计研发过程中不断偏离需求时，此时需求文档作为一份需求评审时已统一目标的文档，有利于团队回归到产品设计的正轨上，保障产品按照目标顺利完成上线。4. 产品需求文档有利于产品迭代管理中回溯此前需求的设计及规划产品迭代管理中，我们可以回溯上一版需求文档中的迭代计划的背景及需求的目标，结合当前的效果及不足，做出系新的迭代的规划。对与一个项目组新的产品经理来说，了解过往的产品需求文档可以更好地了解产品的内在逻辑和外在表现。四、 怎么写产品需求文档（模板干货）
接下来就是实打实的产品需求文档模板（根据具体情况选用）干货啦！
五、从产品思维出发，借助PRD推动需求落地
产品需求文档是产品策划流程中贯穿始终的工具，业界也有不少成熟的需求文档模板参考，但是如何能让产品需求文档成为有效的工具，帮助产品经理推动需求落地是值得思考并尝试解决的问题。输出一份系统化可参考的方法论有助于产品经理避开不少弯路。运用产品思维去思考如何解决问题能帮助我们把解决问题的方案进一步标准化、产品化，从而用最少的时间和精力，实现最大化效果。因此，我尝试用自己浅薄的经验，运用产品思维去总结输出一份可参考复用的方法论，希望能帮助到同样作为产品新人的同学们写好PRD，推动需求落地上线。从我的经验来看，没有写好PRD导致需求没有对齐的情况有以下几个原因：①没有站在阅读对象的角度思考他们希望在PRD上获取什么信息其次，解决问题。为了解决上述的问题，我尝试从用户思维、结构化思维、闭环思维来帮助思考和解决问题。1. 用户思维：站在用户视角，提升用户体验
用户思维，顾名思义，就是“站在用户的角度来思考问题”的思维。使得需求落地前期最为关键的一步，是将需求定义及描述清楚。为了让协同的人员理解需求，产品经理需要站在他们的视角，了解他们的工作场景及诉求，输出解决方案。① 设计师
诉求：项目基于什么背景、有什么目标、目标用户的特点、整体功能有哪些、信息的架构、当前的业务状况如何、需要达到什么样的效果、未来的规划方向解决：简明扼要的背景及目标让设计师准确理解项目的需求。分析目标用户的特点有助于设计师更好地输出用户旅程地图，设计更好的用户体验。功能架构图及信息架构图帮助设计师梳理复杂内容的信息组成，避免信息内容在展示过程中出现遗漏、混乱、重复。如是迭代的需求，告知设计师当前的业务状况及需要达到的效果，可以让设计师更好的明确本次设计目标。提前规划好产品的需求，有助于设计师设计时预留扩展空间，使得设计更具灵活性，易于扩展。② 前端工程师
工作场景：搭建页面，交互实现，功能实现，接口联调，埋点实现诉求：页面的元素、样式、业务逻辑、功能逻辑、交互逻辑、埋点统计解决：具体需求中配图应在交互定稿后替换上最终的交互稿，在说明中详细解释重要的元素、规则及交互。如有统计要求，应有数据埋点的模块，告知前端相应的指标需求，详细描述该指标是何种事件触发的。③ 后端工程师
工作场景：搭建数据库，定义数据结构，建表，实现功能逻辑，编写接口，接口联调解决：功能列表清单有助于后端工程师据此编写相应功能的接口，在数据传递较多（表单等）的需求中，数据字典有助于后端工程师更好了解业务的需求，基于此定义数据结构、建库、建表。④ 测试工程师
解决：功能多的时候，最好有功能列表清单，方便测试工程师针对功能点编写测试用例。具体需求内对每个点的交互、规则、元素描述清楚总的来说，贴合各协同人员的诉求，依据实际情况，用简单清晰的表述为各协同人员提供其工作时需要了解到的产品需求相关的信息，即是运用了“用户思维”去写好一篇产品需求文档，推动产品需求在各环节中的顺利进展。2. 结构化思维：结论先行，突出重点
结构化思维的本质是框架。是从无序到有序的一种思考过程，将搜集到的信息、数据、知识等素材按一定的逻辑进行归总，继而让繁杂的问题简单化；从而让我们的大脑更快速、更有效的处理信息。① 产品需求文档应从宏观到微观地进行铺展，因而需要先写总体需求（依据实际情况可附上业务流程、功能列表清单、功能结构图、信息架构图、角色权限等），再写具体需求（详细讲解需求的流程、规则和实现）。② 使用结构化思维去进行思考和表达时：结论先行，再去展开阐述，先突出重点，能够让对方更加轻松地理解我们想表达的观点。如编写背景及目标时，可先写总的结论，在分点详细阐述,对需要关注的地方进行加粗，避免大段文字的叙述。③ 业务流程图绘制也可采用结构化的思维。在进行流程图的绘制过程中，只有一个流程主线，可使得流程图脉络清晰，业务明了。如果异常流程非常复杂，针对每一个流程节点，如果出现异常流程，可以建立子流程模块，在子流程中标记出异常场景的分支流程；然后把子流程链接到流程概图。3. 闭环思维：有始有终，推动问题解决
闭环思维是指我们在做一件事情时，要做到有始有终。不是仅仅把事情做了，而是要保证事情做了以后，是能够解决问题，或者有相应的见效或进展的。① 依据评审后的讨论结果，不断修正产品需求文档。在需求评审前，产品经理已经输出了第一份产品需求文档。但这个产品需求并非初步方案就能够解决问题，在历经交互、开发评审后，才会最终敲定方案。因此，我们需要不断地修正需求文档并同步给各协同人员。当然，也应该附上相应的修订记录，但由于工具的发展，我们可以依赖工具的变更历史来回顾修订记录，因此不再需要在需求文档上附上修订记录。② 产品需求文档解决的不仅仅是当前的一个问题，也是规划推动下一个问题的解决。尽管每次迭代的目标细分不一样，但是总体的目标都是把产品做好。因而为了推动这个终极目标的实现，我们需要明确清楚每一次迭代需求的目标（注意同步各协同人员本次需求的目标）并且规划好下一个迭代的需求，才能不断推动问题解决，得到良性循环，使得目标越来越近。六、 总结
产品需求文档是每一次产品迭代工作流程中的重要产物。作为产品经理，也许我们已经习惯了自觉输出一份产品需求文档，仿佛PRD是一份工作产出的检验物。但是，产品经理需要有产品的主人翁意识，推动产品需求的落地上线并不断检验。因此，我们应当把PRD作为推动需求落地上线的指导纲领，提高产研效率的有效工具，将产品思维的思考方式运用到策划工作中。我们需要不断总结思考每次的实践，并加以抽象化系统化的形成方法论，再运用到下一次的实践中，反复思考优化方法论，为类似的工作提供可参考的方法。